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@ A standardized message processing procedure 
is invoked by an application program to generate 
informative messages. Message repositories are pro- 
vided in files accessible to the message processor. 
A separate repository is provided for each national 
language which is supported. The application in- 
vokes the message processor, passing variable in- 
formation for inclusion in a message. The message 
processor retrieves the message syntax and fixed 
fields from the appropriate repository, assembles the 
message using information from the repository and 
information provided by the invoking application, and 
generates the message. A preprocessor can be used 
to generate the repository files, and macros suitable 
for inclusion in application source files to invoke the 
message processor 
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MESSAGE PROCESSING SYSTEM 



The present invention relates generally to digi- 
tal computer systems, and more specifically to a 
system for processing and displaying informative 
messages to a user of the computer system. 

Programs running on computer systems must s 
communicate information to a user of the system 
and to other programs. Large programs, such as 
operating systems and product applications, have a 
large number of informative messages which must 
be communicated to a system operator or a user io 
from time to time. 

These messages may simply be informative 
messages, such as those informing a user that an 
action has been completed or a resource is now 
available. Some messages could be considered as 75 
warning messages, which inform a user that some- 
thing is not as expected, such as a file not being in 
the expected format. Critical messages, or error 
messages, can be considered to be those mes- 
sages which inform a user that an attempted action 20 
failed, such as an attempt to open a file which did 
not exist. A significant amount of code in large 
applications such as operating systems can be 
dedicated to handling such informative messages. 

Messages to be read by a user or operator 25 
must be presented in a language understood by 
that person. These languages are often referred to 
as "national languages" to distinguish them from 
programming languages. The message generating 
code must be written with knowledge of the end 30 
user's national language. Changes and updates 
typically involve recompiling the entire application. 

Since different national languages can vary 
quite significantly in syntax (for example, some 
national languages read right to left and others 35 
read left to right, and grammar varies from lan- 
guage to language), translation can be a time con- 
suming task. In addition, significant changes can be 
introduced into the source code for the message 
handling subsystem. Maintenance and support be- 40 
comes much more difficult for products made avail- 
able in numerous countries having different national 
languages when different source code was used to 
generate that product for each different country. 
Errors found in one national language version will 45 
not necessarily be found in other versions, and 
updates and changes to the application as a whole 
becomes more difficult. 

Viewed from one aspect the invention provides 
a data processing apparatus having means for gen- so 
erating a message comprising: 
message processor logic callable from an execut- 
ing application; and 

means storing a first file, accessible by said mes- 
sage processor logic, which defines message syn- 



tax and fixed field content information; 
wherein said message processor logic combines 
information from said first file corresponding to a 
desired message with information supplied by the 
executing application to generate the message. 

The invention provides a message processing 
system for larger applications which addresses the 
problem of the need to recompile or re-link-edit for 
each change. Also, the invention provides a mes- 
sage processing system to gracefully and flexibly 
handle different national languages without intro- 
ducing a number of different source code versions. 

Thus, in one embodiment, a standardized mes- 
sage processing procedure is called by an applica- 
tion program to generate informative messages. 
Message repositories are provided in files acces- 
sible to the message processor. A separate reposi- 
tory is provided for each national language which is 
supported. The application calls the message pro- 
cessor, passing variable information for inclusion in 
a message. The message processor retrieves the 
message syntax and fixed fields from the appro- 
priate repository, assembles the message using 
information from the repository and information 
provided by the calling application, and generates 
the message. A preprocessor can be used to gen- 
erate the repository files, macros suitable for inclu- 
sion in application source files to call the message 
processor system, and to generate documentation. 
The preprocessor performs these functions using a 
single standard message description file as input. 

An embodiment of the invention will now be 
described, by way of example only, with reference 
to the accompanying drawings in which: 

Figure 1 is a high level block diagram showing 
the relationship of a message processor system 
to an application; 

Figure 2 illustrates the combination of fixed field 
and variable field information by the message 
processor to generate a message; 
Figure 3 is a flowchart describing the operation 
of the message processor; 
Figure 4 is a high level block diagram illustrat- 
ing functions performed by a message 
preprocessor; 

Figure 5 is a flowchart describing operation of 
the message preprocessor to generate docu- 
mentation; 

Figure 6 is a flowchart describing operation of 
the message preprocessor to generate a reposi- 
tory file; and 

Figure 7 is a flowchart describing operation of 
the message preprocessor to generate source 
code macros for inclusion in an application 
source file. 
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The description below explains the use of an 
embodiment of a message processor according to 
the present invention in the context of its use with 
an application program. It will be understood by 
those skilled in the art that such a message pro- 
cessing system may be used with many different 
types of applications, including operating systems. 

Referring to Figure 1, an application program 
10 executes on a general purpose digital computer 
as known in the art. The type of computer used is 
not important to the present invention, and may be, 
for example, a mainframe computer system, a de- 
sktop personal computer, or a personal workstation. 
The details of the application program 10 are also 
not important to the present invention. The applica- 
tion program 10 may be, for example, a real-time, 
multi-user operating system supporting graphics 
workstations connected to a network, or it may be 
a single-user application executing on a desktop 
personal computer. 

A message processor 12 is a callable proce- 
dure which executes on the computer system. Dur- 
ing operation, the message processor 12 reads in 
the contents of a message repository 14, which 
consists of information, described in more detail 
below, contained in a file. Additional message re- 
positories 16, 18 may be provided. 

Each message repository 14, 16, 18 contains 
information describing the message syntax and 
fixed fields for a different national language. Each 
message repository 14, 16, 18 corresponds to one 
national language. The message processor 12 ob- 
tains fixed field and syntax information from the 
message repository 14, combines it with variable 
information obtained from the application program 
10, and generates an output string defining a for- 
matted message 20. 

The data utilized by the message processor 12 
in generating a formatted message 20 is illustrated 
in Figure 2. The information passed to the mes- 
sage processor 12 from the application 10 is shown 
in block 22. The information obtained from an entry 
in the message repository 14 is shown in block 24. 
The information listed in blocks 22 and 24 is illus- 
trative only, and may be modified as necessary to 
fit various application and system requirements. 

When invoking the message processor 12, the 
application program 10 passes the information in 
box 22 to the message processor 12 in a data 
structure. It is possible to pass a copy of the entire 
data structure, but the application program 10 pref- 
erably passes only a pointer to a data structure, 
allowing that information to be accessed by the 
message processor 12. The first item in the data 
structure is a message IDENTIFIER, which is pref- 
erably an alphanumeric string identifying the mes- 
sage to be generated. 

The second item passed to the message pro- 
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cesser 12 is a count VAR COUNT of the number 

of variables used by this message. A series of 

variable field descriptors DESC_1 DESC_N, 

describe the field type and field name for each of 
5 the variable fields. A corresponding number of vari- 
able fields VAR 1 , .... VAR N, contain the actual 

variable information. 

When the message processor 12 is invoked, it 
extracts the message identifier and uses that in- 
to formation to search in the message repository 14. 
When the entry in the repository 14 is found which 
corresponds to the identifier, that entry is read in 
and used by the message processor 12 to format 
the message. The information shown in box 24 is a 
15 sample of one entry extracted from the repository 
14. 

Each entry in a message repository 14 in- 
cludes an IDENTIFIER which is matched with the 
identifier provided by the application program 10. 

20 The entry then provides a series of fixed field 
strings and variable field descriptors in the order 
desired for the output message 20. Fixed fields 
provided by the repository entry are simply copied 
to the output string representing the formatted 

25 message 20, and the variables corresponding to 
each of the variable field descriptors are extracted 
from the data structure passed during the invoca- 
tion of the message processor 12, formatted if 
necessary, and copied to the output string. The 

30 output string shown in Figure 2 has alternating 
fixed fields and variable fields, but it is possible for 
both fixed fields and variables to be placed adja- 
cent to other fields of the same type. In general, 
two adjacent fixed fields would be combined into a 

35 longer, single fixed field. 

The output string 20 is therefore seen to have 
a format defined by an entry in the repository 14, 
and contains fixed fields provided by the repository 
14 and variable field values provided by the ap- 

40 plication 10 through the invocation of the message 
processor 12. To use this system with a different 
national language, it is necessary only to define a 
different repository 16 or 18 as the message re- 
pository to be used by the message processor 12. 

45 The message processor 12 will then find the cor- 
responding entry in such other message repository, 
and use that entry to provide the fixed fields and 
format for the formatted message 20. When a 
different message repository 16, 18 is selected, it 

50 would generally be expected that the fixed fields 
within the message repository would be different, 
being written in a different national language. In 
addition, the order in which the variable fields are 
inserted into the output string may also be different 

55 in order to generate an output message having 
correct syntax according to the other national lan- 
guage. 

Since each of the variable descriptor fields 

3 
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provided during the invocation and found in the 
message repository 14 have associated variable 
field names, it is a fairly straightforward process for 
the message processor to match up the variables 
provided in box 22 with the corresponding posi- 
tions defined in the repository entry. For example, 
in Figure 2, the first variable field is DESC_2 
which has a unique name associated therewith. 
The message processor 12 simply scans the 
names found in the variable field descriptors in box 
22 until a match occurs. The corresponding vari- 
able is then copied into the output string. 

The flowchart of Figure 3 illustrates the opera- 
tion of the message processor 12 during construc- 
tion of the formatted message 20. The first step is 
to receive the message request 30. A message is 
reguested by invoking the message processor 12 
and passing to it a pointer to a structure containing 
the message identifier and variable fields as de- 
scribed above. The message processor 12 iden- 
tifies the message 32 with the message identifier, 
and passes the input 34. Since the same invocation 
is used for all messages to be generated by the 
stem, the message processor 12 must use the 
variable count field and variable field descriptors to 
extract the contents of each variable. 

The message processor 12 then determines 
whether the requested message is contained in the 
message repository 36. First, the national language 
repository to be used is determined. This can be 
accomplished by, for example, testing the value of 
a global or system variable used for this purpose. 
The requested message identifier is then matched 
with those in the message repository file as de- 
scribed above. If the message is not defined in the 
repository, an error report is returned 38 and the 
message processor 12 returns to its invoker. Im- 
plementation of the error report returned at step 38 
will be determined by the preferences of the sys- 
tem designer and any previously existing con- 
straints provided by the system. One technique 
would be to generate a formatted message stating 
that there is an unknown error type, and including 
the contents of all of the variable fields passed to 
the message processor 12. 

If the requested message is found in the mes- 
sage repository file, the message identifier is 
copies to the output string 40. The message pro- 
cessor 12 then begins scanning the entries read in 
from the message repository file. If the next field 
42 is fixed, it is simply copied from the message 
repository entry to the current end of the output 
string 44. If the next field is a variable field descrip- 
tor, a check is made 45 to see if a corresponding 
field descriptor exists in the data structure passed 
to the message processor 12. If not, an error mes- 
sage is returned 46 and the process ends. If a 
corresponding field descriptor is located, the vari- 
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able is located in the structure passed to the mes- 
sage processor 12 and converted 47, if necessary, 
and appended to the current end of the output 
string 48. The description field for each variable in 

5 the repository entry preferably contains information 
used in the conversion such as maximum field 
length, justification within the field, and so forth. 
Numeric variables are converted to printable 
strings in step 46 prior to appending them to the 

10 output string in step 48. 

Once the message processor 12 has written 
information to the output string for a given field, a 
check is made to see if there are further fields 
described in the repository entry 50. If so, control 

75 returns to step 42. If not the output string has been 
completely assembled, and the formatted message 
is delivered 52 to a location defined in the mes- 
sage repository entry. The formatted message may 
be delivered to, for example, the system error 

20 stream, directly to the user, or to a preselected file. 

It will therefore be seen that use of a message 
processor as described above in conjunction with 
one or more message repository files allows for 
great flexibility in the use of a standardized mes- 

25 sage processing facility. In order to provide support 
for a new national language, it is necessary only to 
provide a new repository file for that national lan- 
guage. Messages can be changed, added, or de- 
leted, simply by modifying the message repository 

30 file. If changes are made to the application pro- 
gram it is not necessary to recompile the message 
processor 12. Since the message processor 12 is 
an independent procedure invoked using a stan- 
dard format, it is possible to use it with application 

35 programs written in different programming lan- 
guages. 

Another advantage obtainable using the pre- 
ferred embodiment is the use of a single source 
file defining the messages to be supported by the 

40 system. This source file may be used by a 
preprocessor to provide documentation, generate 
the message repository files, and generate source 
code to be placed into the invoking application to 
properly interface such application with the mes- 

45 sage processor. 

Referring to Figure 4, a system is shown 
which uses a message preprocessor 60 to gen- 
erate a documentation file, a message repository 
file, and source code macros for inclusion in the 

so source code file of the calling application. As will 
be described in further detail in connection with 
Figure 5-7, the message preprocessor 60 performs 
these functions on a message definition file 68. The 
message definition file 68 is simply a text file which 

55 defines the format of each message. This format 
definition may be made in any convenient standard 
form. 

For each message defined by the message 
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definition file 68, information is included defining 
the message identifier, and the type of each mes- 
sage field. For each fixed field, a text string value 
for that field is set forth, and for variable fields the 
type of variable and printed format specification are 
included. 

Referring to Figure 5, a preferred method is 
shown by which the message preprocessor 60 
generates a documentation file 62 from a message 
def inition file 68. First, the input/output files are 
opened 80. A text file is open for output as the 
documentation file 62, and the message definition 
file 68 is open for input An outer loop is then 
entered beginning with step 82. In step 82, if no 
more messages remain to be processed in the 
message definition file 68, the procedure ends. 

If messages do remain to be processed, an 
inner loop consisting of steps 84-92 is entered. 
Within this loop, each field is read 84 from the 
message definition file 68. and its field type 
checked 86. If it is a fixed field, its value is simply 
copied to the output file 88. If the field is a variable 
field, the variable name, found in the variable field 
declaration as described in connection with Figure 
2, is copied to the output file 90. If this is not the 
last field in this message 92, control returns to step 
84. If this is the end of the message 92, control 
returns to step 82. 

The documentation file created by the proce- 
dure of Figure 5 is a series of listings showing the 
output format of the various messages in the mes- 
sage definition file. If desired, additional descriptive 
comments can be included in special comment 
fields within the message definition file 68, and 
these descriptive comments can be copied over to 
the documentation file 62. 

Referring to Figure 6, a procedure is shown by 
which the message preprocessor 60 generates a 
■ message repository file 64. To start, the message 
definition file 68 is opened for input and the mes- 
sage repository file 64 is opened for output 100. An 
outer loop is then entered, and a check is made to 
see if any more messages remain to be processed 
102 from the message definition file 68. If no 
messages remain, the procedure ends. 

If any messages do remain, a new entry is 
created in the repository file 64 and the message 
identifier is written into that entry 104. The proce- 
dure then enters an inner loop in which the next 
field is read 106 from the message definition file 
68. The field type is checked 108, and if it is a 
fixed field an identifying sequence number and the 
content of the field are written to the repository file 
110. If the field is a variable field, an identifying 
sequence number and a variable field descriptor is 
written into the repository file 112 as described in 
connection with Figure 2. The variable field de- 
scriptor written in step 112 preferably contains the 
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variable name, variable type, and formatting in- 
formation, often referred to as the picture. 

After the information corresponding to a field 
has been written into the message repository file 

5 64, a check is made to see if this is the last field of 
the message 114. If not, control returns to step 
106. If this is the end of the message, control 
returns to the top of the outer loop at step 102. 
As can be seen by comparison of the 

70 flowcharts in Figures 5 and 6, many similar oper- 
ational steps are performed when generating the 
documentation file 62 and the message repository 
file 64. As will be seen in connection with Figure 7, 
this is also true when generating the message 

75 application source code macro file 66. Thus, it is 
possible to generate all three of these files 62, 64, 
66 at the same time, if desired, from a single 
source input. 

Referring to Figure 7, a procedure is shown for 

20 the message preprocessor 60 to generate the 
source code macros for insertion into the source 
code of the invoking application. First, the message 
definition file 68 is opened for input and the mes- 
sage macro file 66 is opened for output 120. Typi- 

25 caJly, the source code needed for all messages is 
included in a single message macro file 66 which 
is included in the source of the operating system 
10 during compilation. The message preprocessor 
60 then determines the target language 122, which 

30 is the language in which the invoking application is 
written. This is typically supplied by a command 
line switch when the message preprocessor 60 is 
invoked. 

An outer loop is then entered, and the mes- 

35 sage definition file 68 is checked to see if there are 
any more messages 124. If not, the procedure 
completes. If there are more messages to process, 
it is necessary to define a data structure for use by 
the invoking application to pass a message. There- 

40 fore, a structure header is written out 126. The 
structure header contains the code to define a data 
structure, as well as field definitions for the mes- 
sage identifier field and variable field descriptors. 
The procedure then enters an inner loop and reads 

45 the next field 128 within the message. The field 
type is checked 130, and if it is a variable field a 
corresponding entry is written into the source code 
data structure 132. Fixed fields are simply skipped, 
with control passing to step 134. If this is not the 

50 last field of the message 134, control returns to 
step 128. If this is the end of the message 134, 
control passes to step 136. 

At this point, a user-defined structured data 
type has been defined in source code within the 

55 message macro file 66. Each variable to be passed 
has a descriptor field and a value field defined in 
the structure. In general, rather than burdening the 
writer of the calling application with the details of 

5 
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passing parameters to the message processor 112, 
it is preferable to write a macro which is translated 
at compile time into the necessary instructions to 
allocate space for a memory object to be passed to 
the message processor 12, and place the appro- 
priate values into it. Use of macros in such manner, 
in general, is well known to those skilled in the art 

Therefore, the next step is to write code into 
the message macro file 66 to parse the macro 
parameters 136 and assign them to the corre- 
sponding variables within the data structure 138. 
The last step in the macro is to invoke the mes- 
sage processor 12, and pass it a pointer to the 
allocated structure. The structure was allocated 
space during step 136 or step 138, and is defined 
by the type defined during steps 126 through 134. 

As will be appreciated by those skilled in the 
art, the system described above provides for great- 
ly simplified generation and maintenance of a mes- 
sage generation facility suitable for use with mul- 
tiple national languages. A standard message pro- 
cessor procedure can be used by many different 
applications. Such procedure need not be recom- 
piled or relinked when a new national language 
becomes supported by an existing application, be- 
cause ail of the national language dependent in- 
formation is contained in the message repository 
files. 

Since the message processor accepts data in a 
standard format, it can be used with application 
programs written in different programming lan- 
guages. It is preferably provided as a run-time 
module which is simply linked to the application 
program at link time. The message preprocessor 
handles the generation of interface source code 
which must be included in the source file of the 
application at compile time, so that the application 
programmer is not burdened with these details. A 
single message description file can be used by the 
preprocessor to generate source code macros, the 
message repository file, and documentation. 

In at least the preferred embodiment the 
present invention provides a message processing 
system for use with computer applications which is 
independent of the national language in which the 
messages are to be displayed, which does not 
need to be recompiled or re-linked when changes 
are made to the messages supported by the sys- 
tem, and which can be used without modification 
for applications written in different programming 
languages. 

While the invention has been particularly 
shown and described with reference to a preferred 
embodiment, it will be understood by those skilled 
in the art that various changes in form and detail 
may be made therein without departing from the 
spirit and scope of the invention. 



Claims 

1. A data processing apparatus having means for 
generating a message comprising: 

5 message processor logic callable from an execut- 
ing application; and 

means storing a first file, accessible by said mes- 
sage processor logic, which defines message syn- 
tax and fixed field content information; 
w wherein said message processor logic combines 
information from said first file corresponding to a 
desired message with information supplied by the 
executing application to generate the message. 

2. A data processing apparatus as claimed in claim 
75 1, further comprising: 

means storing a plurality of additional files which 
define message syntax and fixed field contents, - 
wherein each of said additional files and said first 
file correspond to a different national language, 
20 whereby the message is generated in the national 
language corresponding to one of said files se- 
lected for use by said message processor logic. 

3. A data processing apparatus as claimed in any 
of claims 1 or 2, wherein said message processor 

25 logic is invoked using a standard format indepen- 
dent of a programming language in which the ex- 
ecuting application is written. 

4. A data processing apparatus as claimed in any 
of claims 1, 2 or 3, wherein the information sup- 

30 plied by the executing application includes a mes- 
sage identifier. 

5. A data processing apparatus as claimed in claim 
4, wherein the information supplied by the execut- 
ing application further includes at least one variable 

35 and an associated variable field descriptor. 

6. A data processing apparatus as claimed in any 
of claims 4 or 5, wherein the message syntax 
information contained in said first file includes vari- 
able position information and associated variable 

40 field descriptors containing a field name, wherein 
the variable field descriptor supplied by the execut- 
ing application also contains a field name, and 
wherein the variable supplied by the executing 
application is positioned in the generated message 

45 by comparing its associated field name with the 
field names contained in said first file information 
and placing the variable in a corresponding posi- 
tion. 

7. A data processing apparatus as claimed in any 
so preceding claim, further comprising: 

message preprocessor logic for generating said 
first file from a message description file which 
defines message syntax. 

8. A data processing apparatus as claimed in claim 
55 7, wherein said message preprocessor logic also 

generates, from the message description file, pro- 
gram source code to be inserted into source code 
for the executing application upon compilation 
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thereof, wherein such inserted source code inter- 
faces the executing application with said message 
processor logic. 

9. A method for processing messages during ex- 
ecution of an application program on a data pro- 5 
cessing apparatus, comprising the steps of: 

passing a message identifier to message processor 
logic; 

obtaining a message syntax and fixed field values 
corresponding to the message identifier from a 10 
repository file; and 

generating an output message containing fixed field 
values according to the syntax obtained from the 
repository file. 

10. A method as claimed in claim 9, further com- 15 
prising the step of: 

passing variable field values to the message pro- 
cessor logic; 

wherein said generating step generates an output 
message which contains the variable field values in 20 
addition to the fixed field values. 

11. A method as claimed in claim 10, wherein 
variable field descriptors associated with the vari- 
able field values are also passed to the message 
processor logic, wherein the message syntax in- 25 
eludes variable field descriptors, and wherein the 
passed variable field descriptors are compared to 

the variable field descriptors contained in the mes- 
sage syntax to determine a location for the asso- 
ciated variable field values within the output mes- 30 
sage. 

12. A method as claimed in claim 11, further com- 
prising the step of: 

if any variables passed to the message processor 
logic do not have a corresponding variable field 35 
descriptor in the repository file, then generating an 
error message. 

13. A method as claimed in any of claims 9 to 12, 
further comprising the step of: 

if no message syntax and fixed field values cor- 40 
responding to the message identifier are contained 
in the repository file, then generating an error mes- 
sage. 

14. A method as claimed in any of claims 9 to 13, 
further comprising the step of: 45 
generating the repository file from a message de- 
scription file. 
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